\documentclass[11pt,a4paper,spanish,openright,twoside]{report}
\usepackage[spanish,activeacute]{babel}			
\usepackage[utf8]{inputenc}
\usepackage{supertabular}
\usepackage{multirow}
\usepackage{graphicx}
\usepackage[top=2.5cm, bottom=2.25cm, outer=2.75cm, inner=2.75cm, heightrounded, marginparwidth=2.5cm, marginparsep=0.3cm]{geometry}
\usepackage{emptypage}		%para quitar los encabezados de las páginas en blanco
\usepackage[acronym,footnote]{glossaries}
\usepackage{hyperref}
\usepackage{epstopdf}

\usepackage{fancyhdr}		%paquete de encabezados
\pagestyle{fancy}

%%%%% CHAPTERS STYLE %%%%%
\usepackage{fancyhdr}
\usepackage[Bjornstrup]{fncychap}

%%%%	TIPOGRAFIA	%%%%%%
\usepackage[default]{cantarell} %% Use option "defaultsans" to use cantarell as sans serif only
\usepackage[T1]{fontenc}


%contador GCS
\newcounter{GCS}	
\newcounter{GCSii}[GCS]

%%%%%%% ENCABEZADO %%%%%%
\fancyhead{}
\fancyfoot{}
\fancyhead[RO]{\nouppercase{\rightmark}}	%encabezado de pares: nombre de la sección
\fancyfoot[LE,RO]{\thepage}	%abajo a izqda en pares, derecha en impares: numero de pagina
\fancyhead[LE]{GCS. Versión \theGCS.\theGCSii} %cuadro izquierdo de pagina par: parte y contador
\fancyhead[RE]{\nouppercase{\leftmark}}
\cfoot{ADVSM. Cauchy-team}
\renewcommand{\footrulewidth}{0.4pt}
\renewcommand{\headrulewidth}{0.4pt}		% linea por debajo del encabezado
\renewcommand{\sectionmark}[1]{\markright{\textbf{\thesection. #1}}}	%negrita

\input{glosario}

\raggedbottom 

\stepcounter{GCS}
\stepcounter{GCSii}

\begin{document}
\renewcommand{\chaptername}{Apartado}
\ \\
\vspace{3.5cm}

\thispagestyle{empty}



\begin{center}
\rule{16cm}{0.5pt}

\vspace{0.53cm}
\Huge{\textsf{Gestión de configuración software}}\\
\Large{\textsf{Estándar IEEE 828-1998}}

\rule{16cm}{0.5pt}
\end{center}

\begin{center}
\small{(Versión \theGCS.\theGCSii, \today)}\\
\end{center}

\vspace{1cm}

\begin{center}
\includegraphics[scale=0.78]{logo.eps}

\vspace{0.3cm}

Proyecto para \textsc{Skirta, Sociedad Anónima}
\end{center}


\vspace{8cm}
\begin{minipage}{7cm}
\hspace{-1.9cm}\includegraphics[scale=0.43]{cauchyTeam.pdf}
\vspace{-1cm}
\end{minipage}

\tableofcontents

\renewcommand\listtablename{Índice de tablas}
\renewcommand\tablename{Tabla}
\listoftables

\pagebreak

\input{GC_GCS_Gest_conf_sw}

\input{GC_RV_Registro_versiones}

\chapter{Introducción}
\section{Propósito}

En el desarrollo de software los cambios, debidos principalmente a modificaciones de requisitos y fallos, son inevitables. Normalmente se trabaja en equipo 
por lo que es preciso llevar un control y registro de los cambios con el fin de reducir errores, aumentar la calidad y la productividad y evitar los 
problemas que puede acarrear una incorrecta sincronización en dichos cambios, al afectar a otros elementos del sistema o a las tareas realizadas 
por otros miembros del equipo de proyecto.

El objetivo de la gestión de la configuración es mantener la integridad de los productos que se obtienen a lo largo del proceso de desarrollo, 
garantizando que no se realizan cambios incontrolados y que todos los participantes en el sistema disponen de la versión adecuada de los productos 
que manejan. Así, entre los elementos de configuración software, se encuentran no únicamente ejecutables y código fuente, sino también todos 
los documentos generados como las especificaciones de requisitos, el plan de proyecto, las pruebas, etc.

La gestión de configuración facilita el mantenimiento del sistema, aportando información precisa para valorar el impacto de los cambios 
solicitados y reduciendo el tiempo de implementación de un cambio, tanto en la evolución del proyecto como en la corrección de alguna 
parte del mismo. Asimismo, permite controlar el sistema como producto global a lo largo de su desarrollo y obtener informes sobre el 
estado de desarrollo en que se encuentra, lo que se traduce en un aumento de calidad del producto y de la satisfacción del cliente.

El presente documento permite definir las necesidades de gestión de configuración de ADSVM para cada uno de sus producto, recogiéndolas 
en un Plan de Gestión de Configuración, en el que se especifican las actividades de identificación y registro de productos en el 
sistema de gestión de configuración durante el desarrollo y posterior mantenimiento del sistema de información.

Los productos registrados en el sistema de gestión de la configuración se encuentran identificados y localizados unívocamente, 
de manera que la información relativa a los productos es de fácil acceso.

\section{Alcance}
El Plan de configuración está basado en las siguientes premisas:

	\begin{itemize}
	  \item El tiempo de duración del proyecto está limitado a 30 semanas, por lo tanto se busca una rápida respuesta a los cambios, tratando que este procedimiento sea lo menos burocrático posible.
	  \item El Modelo de Proceso Unificado que hemos seguido se basa en un desarrollo incremental, dado por las distintas iteraciones. Resulta importante tener control sobre cada una de las iteraciones y fases, de los productos generados en estas y de los cambios surgidos, evaluados y aprobados.
	  \item Se  deben incluir en control de configuración la mayor cantidad de productos posibles, tomando en cuenta siempre las restricciones dadas por la duración del proyecto y por la capacidad organizativa del grupo.
	  \item La elección de los elementos de configuración se realizará en base a las entregas, el encargado de la misma será el Responsable de la Gestión de Configuración de Software (\gls{RGCS}), apoyado por los integrantes del equipo que han realizado cada uno de los \gls{ECS}.
	\end{itemize}
La gestión de configuración se realiza durante todas las actividades asociadas al desarrollo del sistema, y continúa registrando los cambios hasta que éste deja de utilizarse. Por tanto el Plan de Gestión de la Configuración abarcará todas las fases del ciclo del  proyecto.

Para la realización del mismo seguiremos el estándar IEEE 828-1998.
	
\section{Definición de términos clave}
Consultar el documento \texttt{RQ\_GLO\_Glosario} dónde se recogen los términos usados en el presente documento que son de interés para el usuario del mismo.

\section{Referencias}
\begin{enumerate}
  \item IEEE Std 828-1998, \emph{IEEE Standard for Software Configuration Management Plans} (SCMP).
\end{enumerate}

\chapter{Gestión de la configuración del software}

La Gestión de Configuración es un soporte para la actividad de desarrollo, para que los integrantes del equipo tengan el entorno apropiado para realizar y verificar su trabajo. El responsable \gls{RGCS} proporciona la infraestructura y entorno para la Gestión de Configuración. 

\section{Organización}

	\begin{description}
		\item[\underline{Requisitos:}] En esta línea de trabajo se definen los requisitos del producto, así como el alcance, coste, tiempo, planificación e interfaz de usuario para el producto.
		\item[\underline{Diseño:}] En esta línea de trabajo se realiza el diseño a partir de los requisitos, desarrollando de esta manera una arquitectura acorde a los requisitos y optimizándola.
		\item[\underline{Implementación:}] En esta línea de trabajo se relaciona la producción y desarrollo del código fuente, binarios, etc. Se relaciona fuertemente con Requisitos y Diseño.
		\item[\underline{Verificación:}] Esta línea de trabajo tiene como objetivo verificar cada componente del producto, exigiendo una correcta relación entre los mismos y una implementación adecuada de los requisitos.
	\end{description}

Las líneas de trabajo mencionadas juegan un rol muy importante en el Plan de Configuración, ya que una modificación menor de cualquiera de ellas puede repercutir en el desarrollo del producto entero.

\section{Responsabilidades GCS}

Se nombra a Iñigo Zunzunegui como Responsable de la Configuración del Software. El \gls{RGCS} debe proveer la infraestructura y el entorno de configuración para el proyecto. Debe preocuparse porque todos los integrantes del grupo entiendan y puedan ejecutar las actividades de \gls{GCS} que el Plan les asigna, así como asegurar que éstas sean llevadas a cabo. Seguir la \gls{lineaBase}, controlando las versiones y cambios de ella, son tareas correspondientes a él. El \gls{RGCS} es un apoyo importante para las decisiones que debe tomar el Comité de Control de la Configuración (\gls{CCC}), del que formará parte, junto con el resto de miembros de Cauchy-Team.

Serán cometidos del responsable \gls{GCS}:
	\begin{itemize}
	  \item Identificar los elementos de configuración (\gls{ECS}), estableciendo así la \gls{lineaBase} del proyecto.
	  \item Realizar el seguimiento de la \gls{lineaBase}
	  \item Fijar una política de nomenclatura de los elementos de configuración para facilitar la identificación y ubicación de éstos en el proyecto.
	  \item Llevar a cabo el control de la configuración, estableciendo estándares y procedimientos a seguir con respecto a los cambios para realizar un control formal de los mismos. 
	  \item Proveer de informes de estado de la configuración (\gls{IEC}) mediante el seguimiento del historial de las revisiones y liberaciones.
	  \item Producir la Versión de Producto a Liberar
	  \item Realizar auditorías de la \gls{lineaBase} del software para verificar que el Sistema en desarrollo es consistente y la \gls{lineaBase} está bien definida.
	\end{itemize}
	
	\begin{center}
	\begin{tabular}{|cp{8cm}|} \hline
		Responsable & \makebox[8cm][c]{Actividad} \\ \hline
		Todo el equipo & Someter a control de cambios los elementos a los cuales son responsables. \\ \hline
		Todo el equipo & Aplicar y seguir el Plan de Configuración. \\ \hline
		\gls{RGCS} & Definir la \gls{lineaBase} y transiciones entre esta. \\ \hline
	\end{tabular}
\end{center}
\section{Políticas, directivas y procedimientos aplicables}

Durante el desarrollo del proyecto habrá \gls{ECS} que tengamos bajo control y que formarán parte de lo que llamaremos Ambiente Controlado, mientras que habrá otros de los que no tengamos control y que llamaremos Ambiente Local.

En presencia de conflictos entre el Ambiente Controlado y el Ambiente Local, se deberá resolver primero el conflicto y luego proceder a introducir una nueva versión.

El efecto de esta política es la seguridad que nos proporciona tener centralizado los distintos elementos que forman parte del ambiente controlado, y permite un único punto de referencia sobre estos elementos por parte de los usuarios.

A continuación se hace una breve descripción del proceso de Control de Cambios Formal seguido:

	\begin{itemize}
	  \item Si existe una petición de cambio (\gls{PCI}) el desarrollador la evalúa. lo que genera un informe de petición de cambio
	  \item La Autoridad de Control de Cambios (\gls{ACC}) valora la petición. En nuestro caso y debido a lo reducido del equipo de trabajo la \gls{ACC} será la misma que el \gls{RGCS}.
	  \item Si la \gls{PCI}  es aceptada quedará pendiente de actuación mientras se genera la Orden de Cambio de Ingeniería (\gls{OCI}).
	  \item Se realiza y revisa el cambio y se actualiza la nueva \gls{lineaBase}, adecuando la futura versión a este cambio.
	\end{itemize}
	
	
\chapter{Actividades de la GCS}
La \gls{GCS} identificará las tareas necesarias para gestionar el presente proyecto. Para ello deberá:

	\begin{enumerate}
	  \item Identificar unívocamente cada uno de los \gls{ECS}, nombrándolos y describiéndolos.
	  \item Realizar un control de cambios formal de la \gls{lineaBase}.
	  \item Realización de informe de estado de los \gls{ECS}.
	\end{enumerate}
	
\section{Identificación de la configuración}
\subsection{Identificación de la ECS's}	
En lo que sigue se entenderá por Elemento de Configuración de software (\gls{ECS}) todo documento o código software que haya sido creado como una entidad diferenciada y que se vaya a entregar al cliente, así como cualquier parte del mismo elaborada independientemente del resto del documento del que forma parte. Es el caso del Plan de Riesgos.

Es cometido del \gls{RGCS} decidir cuáles serán elementos de configuración para lo que  tomar en cuenta qué productos serán necesarios cuando se quiera recuperar una versión completa de sistema.

Se debe generar una \gls{lineaBase} por iteración en cada Fase, teniendo en cuenta:

	\begin{itemize}
	  \item Los eventos que dan origen a la \gls{lineaBase}.
	  \item Los \gls{ECS} que serán controlados en la \gls{lineaBase} y formarán parte del ambiente controlado.
	  \item Los procedimientos usados para establecer y cambiar la \gls{lineaBase} (control de cambios formal).
	  \item La autorización requerida para aprobar cambios a los documentos de la \gls{lineaBase} (\gls{ACC}).
	\end{itemize}
	
	\subsection{Nomenclatura de los \gls{ECS}'s}
	En esta sección se detalla la nomenclatura que debe tener cada elemento de configuración de forma que queden identificados unívocamente. Además se especifica cómo se distinguirán las diferentes versiones de cada \gls{ECS}. Hemos optado por la utilización de códigos significativos con el siguiente formato:
	
	\begin{center}
		\texttt{\{Código\}\_v\{Versión\}.\{Extensión\}}
	\end{center}
	
	donde:
	
		\begin{itemize}
		  \item Código: \texttt{\{Disciplina\}\_\{Producto\}\_\{Texto\}}
		  	\begin{description}
		  	  \item[Disciplina: ]  Agrupra varios \gls{ECS} relacionados %ver tabla adjunta¿?
		  	  \item[Producto: ]  Acrónimo del \gls{ECS}.
		  	  \item[Nombre del \gls{ECS}: ] Comienza por mayúsculas y se sustituyen los espacios por guiones bajos.
		  	 \end{description}
		  \item Versión: Número identificativo de la versión.
		  \item Extensión: Extensión del archivo originado.
		\end{itemize}
		
En el caso  que exista algún elemento de configuración que se agregue a los que se detallan abajo, se deberá incluir en las tablas siguientes de acuerdo a la disciplina a la que pertenece.

\begin{center}
\tabletail{}
\bottomcaption{Tabla mostrando los ECS del proyecto}
\tablelasttail{}
\begin{supertabular}{|p{3cm}|p{5.5cm}p{7cm}|}\hline
\textbf{\textsc{Disciplina}} & \textsc{\textbf{Código}} & \textsc{\textbf{Descripción}} \\ \hline
 \multirow{5}[7]{*}{Requisitos (RQ)} & {RQ\_SRS\_Requisitos} & {Especificación de requisitos} \\ \cline{2-3}
 & RQ\_DCU\_Casos\_uso \newline \emph{(agrega RQ\_DIAG\_Diag\_casos\_uso)} & Documento de casos de uso \\ \cline{2-3}
 & RQ\_DIAG\_Diag\_casos\_uso & Diagramas de casos de uso \\ \cline{2-3}
 & RQ\_GLO\_Glosario & Glosario \\ \hline
\multirow{2}{3cm}{Implementación (IM)} & {IM\_PR\_Prototipo} &{ Prototipo de la aplicación} \\\cline{2-3}
& IM\_AP\_Aplicacion & Aplicación definitiva (módulo ventas) \\  \hline
 \multirow{2}[20]{3cm}{Gestión de Configuración (GC)} & {GC\_GCS\_Gest\_config\_sw \emph{(agrega GC\_RV\_Registro\_versiones)}} & {Garantía de calidad del software} \\ \cline{2-3}
 & GC\_RV\_Registro\_versiones & Registro de versiones (carpeta de los historiales de  versiones de cada \gls{ECS}). \\ \hline
\multirow{2}[15]{3cm}{Garantía de calidad (SQA)} & SQA\_SQA\_Plan \emph{(agrega SQA\_RTF\_Revision)}& Plan de garantía de calidad del software \\ \cline{2-3}
& SQA\_RTF\_Revision & Actas y documentos relacionados con las revisiones técnicas formales \\ \hline
 \multirow{3}[30]{3cm}{Gestión de proyecto (GP)} & {GP\_PLA\_Plan\_proyecto \emph{(agrega GP\_EM\_Estimacion\_esfuerzo)}} & Plan de proyecto \\ \cline{2-3}
 & GP\_RSG\_Riesgos & Plan de reducción, supervisión y gestión del riesgo. \\ \cline{2-3}
 & GP\_EM\_Estimacion\_esfuerzo & Estimaciones y mediciones de esfuerzo \\ \hline
Manuales de usuario (UM) & UM\_UM\_Manual\_usuario & Manual de usuario de la apliacion \\ \hline
\multirow{3}{3cm}{Diseño (DS)} & {DS\_DGN\_Diseño \emph{(agrega DS\_DIAG\_Diagramas\_diseño)}} & Documento de Diseño\\ \cline{2-3}
& DS\_DIAG\_Diagramas\_diseño & Diagramas de modelado UML \\ \hline
\end{supertabular}
\end{center}

\emph{Nota.} Debido a lo didáctico del presente proyecto la redacción de este documento ha supuesto que los \gls{ECS} con los que hemos estado trabajando hasta ahora hayan tenido que ser renombrados. Las extensiones siguen siendo las mismas. A continuación se muestra una tabla con las correspondencias de nombres. Si el \gls{ECS} ha sido creado tras la redacción de este Plan ya se adecúa a la nomenclatura aquí descrita.
\begin{table}
\begin{center}
	\begin{tabular}{|cc|}\hline
		Antiguo & Nuevo \\ \hline
		\texttt{masterSRS.tex} & \texttt{RQ\_SRS\_Requisitos} \\ \hline
		\texttt{masterDCU.tex} & \texttt{RQ\_DCU\_Casos\_uso} \\ \hline
		\texttt{diagramas} & \texttt{RQ\_DIAG\_Diag\_casos\_uso} \\ \hline
		\texttt{glosario.tex} & \texttt{RQ\_GLO\_Glosario} \\ \hline
		\texttt{PROT\_1.0.1.exe} & \texttt{IM\_PR\_Prototipo} \\ \hline
		\texttt{masterPlanificacion.tex} & \texttt{GP\_PLA\_Plan\_proyecto} \\ \hline
		\texttt{masterRSGR.tex} & \texttt{GP\_RSG\_Riesgos} \\ \hline
		\texttt{estimacionProyecto.tex} & \texttt{GP\_EM\_Estimacion\_esfuerzo} \\ \hline
	\end{tabular}
\caption{Tabla de equivalencias entre la nomenclatura antigua y la actual}
\end{center}
\end{table}
\subsection{Elementos de la \gls{lineaBase} del proyecto}
En esta sección se debe detallar la \gls{lineaBase}, esto es, los elementos que pertenecen a la \gls{lineaBase} del Proyecto, especificados por Fase del Proyecto y por iteraciones dentro de cada Fase.

Tras las correcciones y actualizaciones del Proyecto llevadas a cabo en la RTF subsiguiente a la segunda entrega de fecha la Línea Base queda como se muestra en la Tabla 3.3.

\begin{table}
\begin{center}
\begin{tabular}[h!]{|cp{6cm}|}\hline

	\multicolumn{2}{|c|}{FASE: Segunda entrega} \\ \hline
	Elemento & \makebox[6cm][c]{Descripción} \\ \hline
	\texttt{RQ\_SRS\_Requisitos\_v2.0.tex} & Especificación de requisitos\\ \hline
	\texttt{RQ\_DCU\_Casos\_uso\_v2.0.tex} & Documento de casos de uso \\ \hline
	\texttt{RQ\_DIAG\_Diag\_casos\_uso\_v1.1.pdf} & Carpeta compuesta por 6 pdf que se agregan al Documento de casos de uso. \\ \hline
	\texttt{IM\_PR\_Prototipo\_v1.0.exe} & Prototipo de la aplicación \\ \hline
	\texttt{GP\_PLA\_Plan\_proyecto\_v1.0.tex} & Plan de proyecto \\ \hline
	\texttt{GP\_RSG\_Riesgos\_v1.0.tex} & Plan de reducción, supervisión y gestión del riesgo \\ \hline
	\texttt{GP\_EM\_Estim\_esfuerzo\_v2.0.tex} & Estimaciones y mediciones de esfuerzo \\ \hline
\end{tabular}
\caption{Elementos de configuración software de la segunda fase.}
\label{tabla:segundaFase}
\end{center}
\end{table}

\subsection{Recuperación de los elementos de configuración}
El ambiente controlado tendrá ubicación en un servidor externo a la facultad, evitando de esta forma posibles fallos de acceso. En concreto se utilizará un repositorio SVN.

Se tendrá acceso al ambiente controlado a través de usuario y contraseña. El usuario será la cuenta de correo electrónico de Google, mientras que la contraseña será la proporcionada por el repositorio que se muestra cuando se ha iniciado sesión con una cuenta asociada al proyecto. Si bien es cierto que cualquiera que sea conocedor del nombre de proyecto podría hacer update del mismo no sería capaz de  realizar cambios en él, lo que proporciona un nivel de seguridad aceptable. Los usuarios deberán seguir los protocolos nombrados a la hora de trabajar con dicho ambiente.

Los archivos fuente deberán ser sometidos al ambiente controlado en su directorio indicado, siendo previamente compilados sin errores y sin advertencias. 

Los cambios sobre cualquier archivo deberán ser brevemente descriptos a la hora de afectarlos en el ambiente controlado.

\section{Control de la configuración}
No procede.

\section{Contabilidad de estado de configuración}

Se muestra a continuación una relación de los \gls{ECS} en la que detallamos el historial de revisiónes de los elementos de configuración de software controlados

\input{GC_GCS_Registro_versiones_1.0/RQ_SRS_Requisitos}

\input{GC_GCS_Registro_versiones_1.0/RQ_DCU_Casos_uso}

\input{GC_GCS_Registro_versiones_1.0/RQ_DIAG_Diag_casos_uso}

\input{GC_GCS_Registro_versiones_1.0/RQ_GLO_Glosario}

\input{GC_GCS_Registro_versiones_1.0/IM_PR_Prototipo}

\input{GC_GCS_Registro_versiones_1.0/GC_GCS_Gest_conf_sw}

\input{GC_GCS_Registro_versiones_1.0/GC_RV_Registro_versiones}

\input{GC_GCS_Registro_versiones_1.0/SQA_SQA_Plan}

\input{GC_GCS_Registro_versiones_1.0/SQA_RTF_Revision}

\input{GC_GCS_Registro_versiones_1.0/GP_PLA_Plan_proyecto}

\input{GC_GCS_Registro_versiones_1.0/GP_RSG_Riesgos}

\input{GC_GCS_Registro_versiones_1.0/GP_EM_Estimacion_esfuerzo}

\input{GC_GCS_Registro_versiones_1.0/UM_UM_Manual_usuario}

\section{Auditorías y revisiones de la configuración}
No procede
\section{Control de interfaz}
No procede.

\section{Control de la subcontratación/compra}
No procede.

\chapter{Planificación de la GCS}
No procede.

\chapter{Recursos de la GCS}
Como ya se ha comentado en este documento se ha asignado a Iñigo Zunzunegui como redactor y mantenedor del presente documento y en el recaerán las tareas de \gls{RGCS} y de \gls{ACC}.

En cuanto a herramientas CASE solo hemos contado con las utilidades del repositorio SVN aunque no es una utilidad específica para estos menesteres. No se ha utilizado ninguna base de datos para el control de versiones cosa que habría sido deseable pero que escapaba a nuestras posibilidades.

\chapter{Mantenimiento del plan de GCS}
No procede.

\end{document}
